Per-pool interval watermarks, and cpu load repairs - #232

Independent of #224 -- this branches from master and does not need the page pool or the reclaim registry.

Groundwork for a system device in openwatt (open-watt/openwatt#532) that shows what memory and CPU are doing over time, so a small target's slide towards an out-of-memory death is visible before it arrives.

Interval watermarks

Sampling used once a second sees the level at that instant and nothing else. Both shapes that precede an OOM death go unseen: the transient spike that nearly exhausted a pool, and the floor creeping up underneath it.

So every alloc and free nudges its pool's low/high pair, and sample_pool_usage() reads the pair and re-arms both to the latest level. Each interval then reports the extremes reached within it. One sampler per pool, since reading consumes the interval. Note and sample race only against each other's precision, and a lost update costs one sample of resolution, which does not justify a CAS loop on the allocation path.

State lives in a new urt.mem.pressure, self-contained. Each platform feeds it from the truest source it has cheaply:

Drivers declare has_pool_usage; those that do not track their own pools ride a fallback hook in urt.mem.alloc, which compiles to nothing on the ones that do.

When #224 lands it brings urt.mem.reclaim, whose threat watermarks keep a running allocation total of their own. Whichever merges second should drop one of the two counters; they are both a single atomic on the same path.

CPU load

Going to report CPU the same way turned up three defects in count_system_load, each fixed in its own commit.

1. The ring is not advanced past busy time. It stepped by (b >> shift) - (a >> shift), the span of the idle interval alone, but g_bucket tracks where the previous wake left off. The busy stretch in between can cross a boundary by itself, and when it does both ends of the new idle span sit in the same later bucket, the step count comes out zero, and the idle is credited to a bucket that closed a while ago:

a=212500(bkt 3) b=250000(bkt 3) fi=0 g_bucket=3 -> cpu[3]=40892
a=262500(bkt 4) b=300000(bkt 4) fi=0 g_bucket=3 -> cpu[3]=78392   <-- capacity is 65536

get_cpu_load then sums more idle than the window holds and total_time - idle_time underflows. Now the ring rolls to where the idle span begins first, filling everything crossed on the way with zero, because none of that time was idle.

2. The stamps wrap. They were truncated to size_t, so on a 32-bit target nanoseconds wrap every 4.3s and the step count is usually garbage. That is what masked defect 1: the count gets clamped and resets the whole ring instead. Bucket numbers are 64-bit now; they are only shifted and compared, so a 32-bit target pays nothing for the width.

3. The percentage overflowed. total_time was about 1.0e9, so cpu_time * 100 left 32 bits above roughly 4% load:

true load   4% -> 4%      true load  50% -> 3%
true load   5% -> 0%      true load 100% -> 1%

Widening the multiply would fix it but costs a libcall on rv32. Decimating to microsecond buckets is better, and is what the second commit does: a whole 16-bucket window is then under 1e6, the load calculation stays a 32-bit multiply and divide, and the resolution given up is 1us against a 65ms bucket.

With those out of the way, get_cpu_load_range() adds the same low/high treatment memory gets. The average flattens exactly the bursts worth seeing: one saturated bucket inside an otherwise quiet second reads as 14% spread across the ring, when the busiest slice in it was 80%.

Verified

• Windows and Linux (WSL) builds, all unit tests green.
• New tests: watermark arm/sample/re-arm and the never-tracked case; and for CPU, a duty cycle whose busy stretch crosses bucket boundaries, the fully-busy and fully-idle ends, a run straddling the 32-bit microsecond wrap, and a saturated bucket the average hides. count_system_load reads the clock itself, so the body is split out as account_idle taking both stamps, which is what the tests drive.
• Load accounting checked against a simulation at 1%/25%/50%/90% duty over 20Hz, 1kHz and 3Hz loops: reported within 1% of true in every case, no bucket ever over capacity, correct either side of the 32-bit wrap.
• Semantic-checked with LDC for Espressif, and for BL808_M0, BL808 and BL618.